• 1.: Would be highly insecure, because it would require every request to carry the password.
• OAuth2 or Kerberos: these are complex protocols, IMHO too complex for what where trying to do here.

So I'm also in favor of a token + secret salt system. That's what have been proposed in shaarli/Shaarli#586. But I'm more in favor of using JWT because it's widely used and there are existing library for clients in any language.

existing library for clients

what library would one need to simply set a header?

and: why should we parse the request payload (json), if we can tell by the header it's not authenticated? JWT appears over-engineered to me (for our purpose).

Because if you only use one hash in the header, I can forge any request if I get your hash (which is contained in every requests).

Why not stick with login/password authentication to begin with?

When emitting several requests over an HTTP service that requires authentication, one usually:

• opens an HTTP session with a first request carrying the credentials,
• reuses this session to send further requests

Then, once an API is well-defined, new means of authentication can be added (e.g. easily renewable/revokable tokens)

That's the exact opposite of what a stateless API should be. While scalability isn't really important for Shaarli, I don't think that creating an authentication service, checking client state, handling logout and reconnections is easier to do than using hash and base64_encode to check a token validity.

don't forget about the client complexity, too.

Here is what a client should do to generate a valid JWT token if we use one hashing algorithm (PHP example):

generateToken($secret, $data) {
  $header = base64_encode(json_encode([ 'alg' => 'HS256', 'typ': 'JWT' ]));
  $body = base64_encode(json_encode($data));
  $signature = hash('sha256', $header .'.'. $body .'.'. $secret);
  return $header .'.'. $body .'.'. $signature;
}

And eventually add a timestamp in the body or header to "burn" the token. With this method neither the password or the 'secret' go through requests.

I believe this method has a good security/complexity balance.

holy shit.

wanted a wiki-edit, not a PR. So closing.

may be ninja-re-opened once #6 is clarified.